home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17416 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.2 KB

  1. Path: nntp-hub.barrnet.net!biosys!paralysys
  2. From: nasser@paralysys (Nasser Abbasi)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Should I called exit() within method of a sub-object and return error info back to caller??
  5. Message-ID: <nh3f656z9w.fsf@paralysys>
  6. Date: 15 Apr 96 19:52:12 GMT
  7. References: <4ka0ta$ivj@tilde.csc.ti.com>
  8. Sender: news@biosys.apldbio.COM
  9. Organization: Applied BioSystems
  10. In-reply-to: Chuach@dlep1.itg.ti.com's message of 8 Apr 96 02:37:45 GMT
  11. To: Chuach@dlep1.itg.ti.com (Chua Chye Heng)
  12. X-Newsreader: Gnus v5.1
  13.  
  14. In article <4ka0ta$ivj@tilde.csc.ti.com> Chuach@dlep1.itg.ti.com (Chua Chye Heng) writes:
  15.  
  16.    From: Chuach@dlep1.itg.ti.com (Chua Chye Heng)
  17.  
  18.    My scenario:
  19.    Obj A uses Obj B to read data out from a definition file. When there
  20.    is a serious error in the definition file, should I called exit inside
  21.    the member function in Obj B or immediately return a BAD_STATUS
  22.    indicator to the caller?? 
  23.  
  24.  
  25. The best way to handle errors in a program is to try to smoothly
  26. rewind the call stack all the way back to main, and back to the 
  27. system level. 
  28.  
  29. This means that calling exit() from deep inside a large a program would
  30. not be a good idea, first of all, object destructors would not get
  31. called, (unless they are all global), and buffers would not get 
  32. flushed out, files will not get closed, smoth landing will not happen !
  33.  
  34. Each function should be responsible of cleaning after itself
  35. if an error occures, then return the status or signal an expection
  36. and let the caller frame do itself, etc.. untill the main line
  37. is reached.
  38.  
  39. using exceptions or returning status are both better choices than
  40. calling exit() IMHO.
  41.  
  42. In some implementation you can declare an exit handler, where by
  43. calling exit() would end up calling the exit handler where you can
  44. do some clean up work, but this is also not a very elegent way of
  45. doing things.
  46.  
  47. Error handling in large programs is not an easy problem, returning
  48. error status has its advantages and disadvangtes, proper use of
  49. exception handling is considered the best way to handle errors
  50. in a program, but that also is not very easy technique to master,
  51. in particular if the exception handling model used by the language
  52. is complicated.
  53.  
  54.  
  55. Nasser
  56.